The need for security in a networked environment is well-known. To provide security, software and/or hardware firewalls have been implemented to permit, deny, and/or proxy data between client(s) and server(s) at specified levels of trust. Further refinements have included implementing multiple firewalls to create a demilitarized zone (DMZ) between public and private networks. A DMZ generally refers to a portion of a company's network that is protected from the Internet by a firewall, includes one or more servers, and protects the internal network against attacks that are blocked by another firewall. Virtually all companies make use of DMZs. Network traffic ordinarily moves from the Internet through an “outer” firewall into the DMZ where it is processed by one or more servers. It then moves through the “inner” firewall to the inside server where the sensitive operation or data is handled.
Network operators have wanted to accommodate incoming SOAP (Simple Object Access Protocol, which refers to a simple XML-based protocol for enabling applications to exchange information over HTTP), EDI (Electronic Data Interchange, commonly used for enabling electronic commerce), and/or other requests (e.g., from the Internet). In particular, they have wanted to allow such incoming requests to go through their DMZs and into their internal networks, but without allowing any direct connections from the DMZ to the internal network.
One solution for accommodating such requests has involved creating an inbound “hole” in the firewall, which still involves a direct connection as above. However, the disadvantages of this design approach are readily apparent and well-known in the art. Also, it will be appreciated that a tunneling approach often introduces undesirable performance overhead and large document processing limitations, in addition to security vulnerabilities.
Another solution provided by the assignee of the instant invention has involved configuring a reverse invoke server for use within the DMZ. By way of analogy, this approach is similar to a situation in which a first person walks up to a second person's house and wants to go in the door, but the first person is not allowed to knock on the door, ring the doorbell, or use the telephone to call inside and ask for the door to be opened. The reverse invoke solution in this analogy is to have the second person who lives in the house occasionally look out the window. If the second person sees someone standing there, that person is let in.
For network traffic, the idea is generally the same. That is, a reverse invoke server located in a DMZ would be periodically or substantially continuously “polled” for work to do (e.g., there is a number of user-configured connections waiting for incoming requests). The solution also is similar to polling where the lookout person is waiting for an indeterminate group of people (e.g., akin to a large message), so that the person waiting has to wait for the last person to arrive (e.g., for the large message to be fully buffered in a storage location) before being able to let that group enter (e.g., to communicate the message to the internal server). This solution is advantageous for a number of reasons. For example, even if someone successfully figures out a way to gain control of the server in the DMZ, that person still could not gain access to the server in the internal network.
However, further enhancements to this basic technique are still possible. Currently, the communication protocols in place before and after the DMZ are different. This configuration adds complexity to the network and tends to require the implementation of at least one proprietary protocol (e.g., between the DMZ and the internal server). Therefore, the entire input message has to be stored at least temporarily (e.g., in memory) in the DMZ Server, e.g., pending protocol and/or data conversion. This configuration also places a limit on the size of message, for example, because the computational resources located within the DMZ may be limited. It also introduces disadvantageous delays. A message essentially is buffered within the DMZ before being passed to the internal server. Also, there is an inherent lag between the successive polls of the reverse invoke server.
Thus, it will be appreciated that there is a need in the art for systems and/or methods that overcome one or more of these and/or other disadvantages. It also will be appreciated that there is a need in the art for improvements to the basic reverse invoke architecture.
An example aspect of certain example embodiments of this invention relates to a streaming reverse HTTP gateway network architecture.
Another example aspect of certain example embodiments relates to accommodating communications over the same protocol before and after the DMZ. By way of example and without limitation, this protocol may be HTTP and, in certain parts of the network, the protocol may be HTTP 1.1. Although a particular version and implementation of the protocol is provided, it will be appreciated that the present invention is not limited thereto, nor is any particular example embodiment limited to a particular version and implementation of a protocol throughout all portions of the network. For example, the protocol implemented may be one or more versions of HTTP and/or HTTPS (e.g., HTTP over SSL) in one or more parts of the network.
Still another example embodiment relates to the maintenance of a substantially persistent reverse connection between an internal server and a reverse HTTP gateway in a DMZ.
In certain example embodiments of this invention, a network is provided. An external firewall and an internal firewall define a DMZ therebetween. An internal network is located behind the internal firewall. An external network is located in front of the external firewall. At least one internal server is connected to the internal network. Each said internal server includes at least one internal registration port. At least one reverse HTTP gateway is located in the DMZ. Each said reverse HTTP gateway includes a reverse proxy port configured to communicate with a client on the external network, and a proxy registration port configured to communicate with one or more internal registration ports of the at least one internal server over a substantially persistent reverse connection between the respective reverse HTTP gateway and the respective internal server. A common communication protocol is implemented on both sides of the DMZ. Any messages between a client on the external network and the at least one internal server are substantially directly streamed therebetween.
In certain other example embodiments, there is provided an HTTP gateway for use in a DMZ located between an external firewall and an internal firewall of a network, with the network including a private network and a public network. A reverse proxy port is configured to communicate with a client on the public network. A proxy registration port is configured to communicate with one or more internal registration ports of at least one internal server provided to the private network over a substantially persistent reverse connection between the HTTP gateway and the respective internal server. A common communication protocol is implemented on both sides of the DMZ. Any messages between a client on the public network and the at least one internal server are substantially directly streamed therebetween.
According to certain example embodiments, a method of configuring a network is provided. An external firewall and an internal firewall are provided so as to define a DMZ therebetween, with an internal network being located behind the internal firewall and an external network being located in front of the external firewall. At least one internal server is connected to the network. Each said internal server includes at least one internal registration port. At least one reverse HTTP gateway is located within the DMZ. Each said reverse HTTP gateway includes a reverse proxy port configured to communicate with a client on the external network, and a proxy registration port configured to communicate with one or more internal registration ports of the at least one internal server over a substantially persistent reverse connection between the respective reverse HTTP gateway and the respective internal server. A common communication protocol is implemented on both sides of the DMZ. Any messages communicated between a client on the external network and the at least one internal server are substantially directly streamed therebetween.
These aspects and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.